oh wow, nice!

• I don't think it should be linked to the wails workflow, can it be a separate workflow? and we can then run it on a specific branch I guess (EDIT: or did you plan to do it by tag)? otherwise we will get a huge number of drafts
• Can you also upload the assets for the other distributions (RPI etc?)
• What would also be a good way to link to the docker build (how would users easily run this exact version using docker)?

@rolznz

Agreed! In fact, I feel it's about time to refactor the GH actions, sort of like Breez does it. We need clearly separated actions for building all the stuff, and a separate release action to run the builds, collect the artifacts, and publish the releases. I will look into it

EDIT: or did you plan to do it by tag

Yeah, exactly. Pushing a new tag would trigger a release

@rdmitr in the future it would be nice to also look if we create a draft release (and create a tag at that point) and then the automation runs at that point

@rolznz I have updated the PR to address the comments :)

I don't think it should be linked to the wails workflow, can it be a separate workflow? and we can then run it on a specific branch I guess

The workflow is now split into actions: first the top-level release.yaml action is triggered (by push for now, but that's for convenience when testing only), then it invokes the Raspberry Pi and Wails actions, followed by the publish-release.yaml action.

What would also be a good way to link to the docker build (how would users easily run this exact version using docker)?

Not sure how to deal with the Docker build, though. Guess we should create Docker images on release, and the users will simply pull the latest image?

Can you also upload the assets for the other distributions (RPI etc?)

Raspberry Pi archive added. However, I have noticed that the Raspberry Pi action publishes a raw zip file. This is problematic, since the executable bit is not preserved (but I see that the update.sh script fixes that). I have added a job step to also produce a .tar.bz2 archive, which is then published in the release. We need to update the update.sh script to fetch the .tar.bz2 archive; then, we will remove the old plain zip artifact from the action.

@reneaaron does that sound ok to you RE: the change to the update.sh script?

I just found it weird to have a zip that contains a another archive, that's why I initially added the executable flags in the update script. No strong opinions here, I guess both is equally fine.

@reneaaron agreed, but raw artifacts are not supposed to be used by the end users, I guess. When we publish a proper Github release, that outer ZIP archive goes away :)